chore: release v0.8.150 - #5495

Reviewed release commit c0bb10e9, signed, and GitHub reports it verified. Its parent is the #5494 merge, fbbc4e88, which is the current tip of main. No blockers, approving. CI is fully green at this head, with 88 checks passed, 0 failed and 0 pending, including all 11 required checks.

Scope: v0.8.149..fbbc4e88 contains 10 commits, all accounted for.

• The notes cover the 7 user-facing ones: #5420, #5454, #5474, #5478, #5481, #5489 and #5494.
• Three are left out of the notes, correctly: #5480 (catalog CI), and #5475 and #5476 (Studio e2e tests only).
• The release commit touches the same 20 files as the v0.8.149 release commit, and nothing else.

Versions

• All 13 public packages are at 0.8.150, and so are the 5 manifests (plugin.json, .claude-plugin, .codex-plugin, .cursor-plugin, gemini-extension.json).
• No 0.8.149 is left outside the changelog and release notes.
• The private sdk-playground stays at 0.6.106, as in earlier releases.
• Internal dependencies are all workspace:* or workspace:^. pnpm publish rewrites those when it packs.
• The CLI is published with npm publish and has no workspace: runtime dependencies.
• bun install --frozen-lockfile passes at this head. The bun.lock workspace version fields are still 0.8.128, the same as in previous releases.

Notes: I checked each bullet against its PR. They are accurate:

• #5420: a root data-fx-chain was previously applied to nothing, so the compatibility note is correct: an unused root chain now affects the mix.
• #5474:
  • The standalone scene uses its own root chain.
  • Mixes over 512 MiB of samples render in 5-minute windows.
  • Automation past 2 GiB now fails with a named AudioFxRenderError.
• #5494: the temporary-URL note is right.
  • Nit, non-blocking: only base64 data:image/... frames get these URLs. Caller-provided frame URLs pass through unchanged. "replaces inline data: frame URIs with temporary URLs" would be more precise.
• releases/v0.8.150.md and the new docs/changelog.mdx entry have the same content.

Publish path: publish.yml, validate-release-channel.mjs, verify-packed-manifests.mjs and package-agent-plugin.mjs are unchanged since v0.8.149.

• Trigger: a stable release publishes only from a merged pull_request from a release/vX.Y.Z branch. A stable tag push is rejected (v*-* only). The checkout is pinned to merge_commit_sha and verified.
• Tag: the tag is created at that SHA, or verified if it already exists there.
• Channel: VERSION=0.8.150 EVENT_NAME=pull_request PR_HEAD_REF=release/v0.8.150 passes the validator with dist-tag latest.
• Not yet published: npm view shows no 0.8.150 for hyperframes or @hyperframes/engine. Neither the v0.8.150 tag nor the GitHub Release exists yet.
• Provenance: the workflow publishes with id-token: write. hyperframes@0.8.149 and @hyperframes/engine@0.8.149 both have SLSA v1 provenance on npm, so this path has produced it before.
• Build and pack: I ran the same steps the post-merge job runs before publishing, at this head, with pnpm 10.17.1 from corepack as in the workflow:
  • bun install --frozen-lockfile and bun run build both pass.
  • bun run verify:packed-manifests reports all 13 packed manifests "publish-safe". It resolved 163 packed exports and ran 153 Node exports. A clean consumer install, TS/Vite resolution and CLI startup all pass, and all 13 packages are within their size budgets.

Note for the post-merge run: the job pushes the v0.8.150 tag before bun run build and before publishing. If build or publish fails, the tag stays while npm has nothing. The fix is to rerun the same merge event, since the tag step verifies an existing tag. That behavior is already there, and this PR doesn't change it.

— tai2